Component-based software development is the current trend in software technologies. A software component may be thought of as a self-contained unit that encapsulates and implements the behavior of a single function.
A complex software system for an organization that spans multiple business functions is normally made up of multiple components. And since the various functions in a business interact with each other, components also need to interact with each other. Development of such multi-component software systems comprising multiple interacting components usually involves multiple development teams with each team responsible for a distinct set of components. The development and roll out may be done in phases with interacting components developed and delivered at different times. For successful development and deployment of such a software system, it is important to be able to develop and test a component in a truly standalone, independent manner, separately test its integration with other components, and subsequently assemble and connect the interacting components together at the deployment stage. The inability to achieve successful development and deployment in software technologies is a problem in the struggle towards creating practical software components. This is compounded by the fact that on a micro-level, the functionality inside the component is not expressible in a standard way for users to understand before they assemble an application using components.
The choice of technologies used to create software further complicates system development because of the lack of standard architectural or structural elements in describing software. Moreover, the functionality provided by software components cannot be abstracted to a reasonably finite set at any point in time. This is in contrast to standard electronic components that pack huge amounts of functionality and behavior into data sheets that describe the various interfaces (pins), properties of information transfer through these interfaces (voltage, signal frequency, etc.), and the expected behavior in terms of the effects on the output interfaces (pins). However, such data sheet based specifications are not available for software components. Rather, software components need fabrication and a certain amount of engineering every time a new application is created. Ironically, even though software is supposedly more malleable, it is electronic components that do not need any engineering to adopt them into an overall functionality. Consequently, problems faced by the industry in making software components include a lack of a standard definition, a lack of an independent production approach, a lack of transparency in functionality and interface properties, and a lack of support needed for making available respective data sheets, assembly instructions, and engineering instructions.
To address some of these problems, generating code out of specifications has been attempted over the past couple of decades. Early approaches involved logic modeling, and later efforts used specifications applied to various sets of diagrammatic conventions to generate code onto target technologies. However, none of the prior attempts were very successful, as they got caught up in the modeled logic, the programming language, or the tediousness of the approach. As a result, the development community reverted back to coding in the conventional way. Consequently, generating code out of specification has up to this point suffered from at least the following drawbacks. First, attempts to generate code for a logic model required extensive detail work at the specification level. This basically transferred the error prone details of development from the details of coding to the details of specification design. Second, even when specifications were used, there has been no standardization of the specification and/or the formal data structures that store and retrieve information. Third, a much needed Change Management process has not been thought out and implemented, causing specifications and models to be out of sync and rendering forward engineering ineffective. Therefore, an issue is the lack of understanding of how to go about creating and managing specifications for software components in such a way that Code generation is possible.
A closely related issue to code generation is the packaging of the generated artifacts (i.e. executable code) for deployment. Currently, deployment packaging varies to a great extent depending on support technologies and the operating system, and packaging the artifacts out of the code generator is a major task in deploying the generated application. Presently, tools in the market are aligned to single support technology and do not cater to multiple support technologies.
Component based software systems have user interfaces that link a user and the system. User interfaces may be a critical part of any software solution since the end user experiences the solution through the user interfaces. User interfaces are many times created by developers who specialize in aesthetics and feel of interfaces. While this makes the interface more creative, it also at times makes it non-standardized. End users do not usually feel comfortable with solutions that require them to operate various user interfaces in many different ways. So in this era of software component assembly, if the user interfaces are not standardized and similar, the resultant assembly will not have consistent usability in user interfaces. Moreover, if there is no standardization, maintenance of the user interfaces becomes more difficult, especially if the interface creator is no longer available.
On the technical level, user interface requirements for some applications can be very demanding. For example, it may be required to capture multiple line items for a document based interface. This is achieved by using a grid control in the user interface. This is even more difficult when the application is Web based. Moreover, it may be required that the application be available on multiple platforms like Windows, UNIX, OS/400, etc., and that it also be available on a wide range of browsers and devices.
One problem with current grid control solutions however is that they are tied to either a particular platform or technology. And a problem with Web based grid controls is that users are very much accustomed to friendly desktop based applications with rich user interfaces. Any Web based control should therefore provide the same rich user interface and ease of use. On the performance side, Web based applications should send as little data as possible over the Web. Because the grid control can hold hundreds of thousands of rows of data, sending all of them over the Web from the client browser to the Web server takes a great deal of time. Since the users are very much used to the fast desktop-based applications, slow Web based applications are not always acceptable.
The drawings described herein are for illustration purposes only and are not intended to limit the scope of the present disclosure in any way.